feat: cross-compile & upgrade LLVM to 21.1.8 - #390
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds cross-compilation support across CI and build tooling: new target triples in GitHub Actions, propagation of Changes
Sequence DiagramsequenceDiagram
participant User
participant CI as CI Runner
participant CMake
participant Toolchain as cmake/toolchain.cmake
participant SetupLLVM as setup-llvm.py
participant Builder as Build (cmake/ninja)
User->>CI: trigger workflow (matrix may set target_triple)
CI->>CMake: run cmake -B build/release ... (-DCLICE_TARGET_TRIPLE=TRIPLE)?
CMake->>Toolchain: read CLICE_TARGET_TRIPLE
Toolchain->>Toolchain: configure system name / processor / compiler target / sysroot
CMake->>SetupLLVM: setup_llvm(... --target-platform=PLATFORM?)
SetupLLVM->>SetupLLVM: select artifact manifest for PLATFORM
CMake->>Builder: cmake --build build/release
Builder->>CI: produce build artifact
CI->>CI: run native or cross prune/apply/upload steps (gated by matrix)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build-llvm.yml (1)
171-216:⚠️ Potential issue | 🟠 MajorMake the prune manifest producer a separate job.
The
+LTOlegs downloadllvm-pruned-libs-${{ matrix.os }}from the samegithub.run_id, but sibling matrix legs have no ordering guarantee. If a consumer leg reachesapplybefore the nativeRelWithDebInfo/OFFleg uploads its artifact, this becomes a flaky CI failure.
🧹 Nitpick comments (3)
config/llvm-manifest.json (1)
1-1: Empty manifest will block builds until regenerated.The manifest is intentionally cleared for the LLVM 21.1.8 upgrade. However, until
build-llvm.ymlandupload-llvm.ymlare run to regenerate artifacts, any build that doesn't have a pre-existing LLVM install will fail inpick_artifact()with "No matching LLVM artifact in manifest".Ensure the follow-up actions (run
build-llvm.yml→upload-llvm.yml) are executed promptly after merging to restore build functionality.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/llvm-manifest.json` at line 1, The LLVM manifest file was cleared for the 21.1.8 upgrade which leaves pick_artifact() unable to find artifacts and will block builds; after merging, immediately run the build workflow (build-llvm.yml) to produce artifacts and then run the upload workflow (upload-llvm.yml) to update config/llvm-manifest.json so pick_artifact() can locate matches; verify the manifest is populated and that pick_artifact() succeeds in CI before closing the change..github/workflows/build-llvm.yml (2)
226-235: Fail fast on unsupported target triples.Right now a typo or future triple addition leaves
ARCH/PLATFORM/TOOLCHAINunset and still produces a malformed artifact name.Suggested hardening
if [[ -n "${{ matrix.target_triple }}" ]]; then case "${{ matrix.target_triple }}" in x86_64-apple-darwin) ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;; aarch64-linux-gnu) ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;; aarch64-pc-windows-msvc) ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;; + *) + echo "Unsupported target triple: ${{ matrix.target_triple }}" >&2 + exit 1 ;; esac else🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 226 - 235, The case block that sets ARCH/PLATFORM/TOOLCHAIN for matrix.target_triple can leave those variables unset for typos or unknown triples; add a default/fallback case in the case statement (for the block handling "${{ matrix.target_triple }}") that logs an explicit error mentioning the unrecognized target triple and exits non‑zero, and also after the case ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set (e.g., test -n "$ARCH" && ...) to fail fast; update references to ARCH/PLATFORM/TOOLCHAIN in the surrounding script to rely on this explicit failure rather than producing malformed artifact names.
198-216: Please validate cross-target pruning before packaging.These legs apply a manifest learned from the native arch and then upload immediately, but they never build a cross-target consumer against the pruned install. If the required LLVM library closure differs by target triple, this workflow can publish a broken archive without noticing. A per-target manifest or a small post-prune link smoke test would make this much safer.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 198 - 216, The workflow applies a native ARCH manifest using the step named "Apply pruned-libs manifest (cross-compile + LTO)" (which calls scripts/prune-llvm-bin.py with MANIFEST="pruned-libs-${{ matrix.os }}.json") but never verifies the pruned install for the cross-target; add a validation step after running prune-llvm-bin.py and before uploading the GH artifact "llvm-pruned-libs-${{ matrix.os }}" that either (a) generates a per-target manifest by running the pruning script on the target toolchain/headers, or (b) performs a small smoke/link test that compiles and links a minimal program against the pruned install at .llvm/build-install/lib (using the matrix.target_triple and matrix.os environment) to ensure all required libraries are present; implement the smoke test as a new step that returns non-zero on failure so the job fails before publishing the artifact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pixi.toml`:
- Line 43: The change added a new workspace constraint sysroot_linux-aarch64 =
"==2.17" in pixi.toml but the pixi.lock file is now out of sync; regenerate the
lock and commit it by running `pixi lock` locally (or in CI), verify the updated
pixi.lock contains the new sysroot_linux-aarch64 entry, and include the updated
pixi.lock in the commit so the pipeline no longer fails.
---
Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 226-235: The case block that sets ARCH/PLATFORM/TOOLCHAIN for
matrix.target_triple can leave those variables unset for typos or unknown
triples; add a default/fallback case in the case statement (for the block
handling "${{ matrix.target_triple }}") that logs an explicit error mentioning
the unrecognized target triple and exits non‑zero, and also after the case
ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set (e.g., test -n
"$ARCH" && ...) to fail fast; update references to ARCH/PLATFORM/TOOLCHAIN in
the surrounding script to rely on this explicit failure rather than producing
malformed artifact names.
- Around line 198-216: The workflow applies a native ARCH manifest using the
step named "Apply pruned-libs manifest (cross-compile + LTO)" (which calls
scripts/prune-llvm-bin.py with MANIFEST="pruned-libs-${{ matrix.os }}.json") but
never verifies the pruned install for the cross-target; add a validation step
after running prune-llvm-bin.py and before uploading the GH artifact
"llvm-pruned-libs-${{ matrix.os }}" that either (a) generates a per-target
manifest by running the pruning script on the target toolchain/headers, or (b)
performs a small smoke/link test that compiles and links a minimal program
against the pruned install at .llvm/build-install/lib (using the
matrix.target_triple and matrix.os environment) to ensure all required libraries
are present; implement the smoke test as a new step that returns non-zero on
failure so the job fails before publishing the artifact.
In `@config/llvm-manifest.json`:
- Line 1: The LLVM manifest file was cleared for the 21.1.8 upgrade which leaves
pick_artifact() unable to find artifacts and will block builds; after merging,
immediately run the build workflow (build-llvm.yml) to produce artifacts and
then run the upload workflow (upload-llvm.yml) to update
config/llvm-manifest.json so pick_artifact() can locate matches; verify the
manifest is populated and that pick_artifact() succeeds in CI before closing the
change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: fbdf875e-89a4-43b2-98a1-39a2520a9284
📒 Files selected for processing (9)
.github/workflows/build-llvm.yml.github/workflows/publish-clice.ymlcmake/llvm.cmakecmake/package.cmakecmake/toolchain.cmakeconfig/llvm-manifest.jsonpixi.tomlscripts/build-llvm.pyscripts/setup-llvm.py
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build-llvm.yml (1)
224-246: Consider adding a fallback case for unknown target triples.The
casestatement handles the three expected target triples but lacks a default case. If a new target triple is added to the matrix without updating this packaging block,ARCH,PLATFORM, andTOOLCHAINwould remain unset, causing a confusing packaging failure downstream.🛡️ Proposed fix to add a fallback case
case "${{ matrix.target_triple }}" in x86_64-apple-darwin) ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;; aarch64-linux-gnu) ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;; aarch64-pc-windows-msvc) ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;; + *) + echo "Error: Unknown target triple '${{ matrix.target_triple }}'" + exit 1 ;; esac🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 224 - 246, The case handling for "${{ matrix.target_triple }}" can leave ARCH/PLATFORM/TOOLCHAIN unset for unknown triples; add a fallback branch (the *) in that case statement to either set sensible defaults (e.g., ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or emit a clear error and exit, and include a warning message that shows the unrecognized "${{ matrix.target_triple }}" so downstream packaging doesn't run with empty variables.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 224-246: The case handling for "${{ matrix.target_triple }}" can
leave ARCH/PLATFORM/TOOLCHAIN unset for unknown triples; add a fallback branch
(the *) in that case statement to either set sensible defaults (e.g.,
ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or emit a clear error and exit,
and include a warning message that shows the unrecognized "${{
matrix.target_triple }}" so downstream packaging doesn't run with empty
variables.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 450a2b15-6fee-4107-bda9-0c147c4c5182
📒 Files selected for processing (1)
.github/workflows/build-llvm.yml
16bit-ykiko
force-pushed
the
feature/cross-compile
branch
from
April 12, 2026 11:34
510693d to
db37b30
Compare
Add CLICE_TARGET_TRIPLE to toolchain.cmake for cross-compilation. Upgrade LLVM from 21.1.4 to 21.1.8 and switch publish workflow from xmake to CMake. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Create three dedicated environments (cross-macos-x64, cross-linux-aarch64, cross-windows-arm64) instead of mixing cross-compile deps into the native build environment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM_USE_SANITIZER=Address is not supported on Windows. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The toolchain.cmake already sets the correct linker (lld-link on Windows, lld elsewhere). LLVM's HandleLLVMOptions.cmake was adding a conflicting -fuse-ld=lld on top of the toolchain's -fuse-ld=lld-link, causing link failures on Windows LTO builds. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM's HandleLLVMOptions generates MSVC-style linker flags (/opt:lldlto, /lldltocache) when LTO is enabled. These are interpreted as file paths by the clang++ GNU driver. Explicitly setting LLVM_USE_LINKER=lld-link tells LLVM's CMake to use the correct flag style. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
clang++ (GNU driver) cannot handle MSVC-style linker flags like /lldltocache: and /opt:lldlto= that LLVM's CMake generates when LTO is enabled. Switch to clang-cl (MSVC driver) on Windows which natively understands these flags. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The package pixi environment doesn't include uv, causing 'uv: command not found' when running integration tests. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add llvm_version and skip_upload inputs to build-llvm workflow - Add upload job to auto-publish artifacts to clice-llvm repo - Add update-clice job to auto-create PR with version bump - Extract distribution components list to scripts/llvm-components.json - Add validate-llvm-components.py to catch stale/renamed components - Add update-llvm-version.py to update manifest and package.cmake Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
LLVM 21.1.8 changed clang-resource-headers from add_custom_target to add_library(... INTERFACE ...). Add add_library pattern to header scanning so the validation script can detect it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Allow uploading artifacts to clice-llvm without creating a PR to update the clice repo. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add architecture (x64/arm64) field to manifest entries so that pick_artifact can correctly select the right artifact when multiple architectures exist for the same platform. Update setup-llvm.py with --target-arch argument and cmake/llvm.cmake to pass it from CLICE_TARGET_TRIPLE. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Revert to 21.1.4+r1 for this PR (version upgrade should come via the automated workflow). Add missing Windows Debug entry to build-llvm matrix. Manifest now includes arch field for all entries. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Update LLVM from 21.1.4+r1 to 21.1.8 - Add cross-compile build targets to test-cmake.yml: macOS x64, Linux arm64, Windows arm64 - Cross-compile jobs build only (no tests) - Windows Debug artifact pending from build-llvm workflow Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GitHub Actions include with cartesian product doesn't create new entries - switch to explicit include-only matrix. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling, the built flatc is for the target architecture and cannot run on the host. Use find_program to locate a host flatc instead. Add flatbuffers conda package to provide it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The flatc version must match the FetchContent flatbuffers library version (v25.9.23) to avoid schema_generated.h compatibility errors. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
clang-cl's -fsanitize=address is incompatible with -MDd (dynamic debug CRT). Skip ASAN on Windows and remove -asan suffix from the Windows Debug artifact name. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On Windows, build-llvm.py uses clang-cl directly instead of the toolchain file, so CLICE_TARGET_TRIPLE wasn't setting the compiler target. Pass --target=<triple> via CMAKE_C/CXX_FLAGS and set LLVM_HOST_TRIPLE for correct cross-compilation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling LLVM (Linux aarch64 from x64, Windows ARM64 from x64), tablegen tools are compiled for the target architecture but must run on the host during the build. Add a two-stage build: first compile native llvm-tblgen, llvm-min-tblgen, and clang-tblgen, then pass LLVM_NATIVE_TOOL_DIR to the cross-compile build. macOS cross-compilation is excluded because Rosetta 2 transparently runs x86_64 tools on ARM64 hosts. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compile + build-only with a native build on windows-11-arm runner. This allows running full tests (unit, integration, smoke) on ARM64 Windows. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The pixi-managed clang on windows-11-arm is an x64 binary running under emulation, defaulting to x64 code generation. Pass CLICE_TARGET_TRIPLE so it generates ARM64 code that matches the ARM64 LLVM libraries. Tests still run natively on the ARM64 runner. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compilation with native runners: - macOS x86_64: macos-13 (Intel) instead of Rosetta on macos-15 - Linux aarch64: ubuntu-24.04-arm instead of QEMU on ubuntu-24.04 - Windows ARM64: windows-11-arm (kept from previous commit) Remove QEMU setup step and build_only logic since all platforms now build and test natively. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
macos-13 runner is no longer available and ubuntu-24.04-arm lacks pixi linux-aarch64 platform packages. Revert these two to the proven cross-compile approach (Rosetta / QEMU). Keep windows-11-arm native runner which works. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…transfer Cross-compile on pixi-supported platforms, upload binaries, then run tests on native runners (macos-15-intel, ubuntu-24.04-arm) instead of QEMU/Rosetta. Add test-run pixi environment for lightweight test-only platform support. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use cross-linux-aarch64 pixi env for Linux aarch64 cross-compilation (provides sysroot, fixes Exec format error on native ARM64 runner) - Upload lib/ directory alongside bin/ (clang resource dir needed by tests) - Remove unnecessary platform restrictions from build/format features Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tforms - Add win-arm64 to pixi platforms (6 total) - Move Windows ARM64 from native build to cross-compile from windows-2025 - All 3 new platforms (macOS x64, Linux aarch64, Windows ARM64) use the same pattern: cross-compile on original platform, test on native runner - Move flatbuffers from workspace deps to build feature (unavailable on win-arm64) - Add platform restrictions for build/format/node features (native tools like cmake, ruff, pnpm unavailable on win-arm64) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…error Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The regex `^aarch64-.*-linux` requires a vendor segment between arch and os (e.g. aarch64-unknown-linux-gnu) but the triple `aarch64-linux-gnu` has no vendor. Change to `^aarch64-.*linux` to match both forms. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's ld_impl_linux-64 sets LIBRARY_PATH=$CONDA_PREFIX/lib which contains x86_64 libgcc_s.so.1. When cross-compiling for aarch64, lld finds this incompatible library and fails. Add activation script to clear LIBRARY_PATH in the cross-linux-aarch64 environment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Pixi's activation script `unset` doesn't propagate through its environment capture mechanism. Use `env -u LIBRARY_PATH` to strip the host x86_64 library path directly before cmake invocation, preventing lld from finding incompatible libgcc_s.so.1. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's cross-compilation toolchain sets LDFLAGS with -L$CONDA_PREFIX/lib pointing to host x86_64 libraries. CMake picks up LDFLAGS from the environment, causing lld to find incompatible libgcc_s.so.1. Strip all conda compiler flags since our toolchain.cmake provides the correct settings. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- build-llvm.py: clear LDFLAGS/CFLAGS/LIBRARY_PATH when cross-compiling to prevent conda's host-platform flags from leaking into the target build - build-llvm.yml: use cross-linux-aarch64/cross-windows-arm64 pixi envs for cross-compile jobs (provides aarch64 sysroot) - build-llvm.yml: add "Build clice" step for cross-compiled LLVM to catch architecture mismatches early - build-llvm.yml: add binary architecture verification step Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous 21.1.8 release contained x86_64 objects in the aarch64 package. After rebuilding with proper cross-compilation sysroot and env var isolation, update the manifest with correct hashes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On macOS runners without upstream clang in PATH, clice falls back to /usr/bin/clang++ (Apple's) which emits vendor-specific flags that upstream LLVM 21 cannot parse, causing 28 unit test failures on macos-15-intel. Add clang/clangxx to the test feature for macOS platforms so test-run gets upstream clang. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Integration tests use CMake with toolchain.cmake which requires -fuse-ld=lld. Without lld in the test-run environment, CMake's compiler check fails on macOS cross-compile test runners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
16bit-ykiko
force-pushed
the
feature/cross-compile
branch
from
April 18, 2026 06:10
1888a6f to
22f8924
Compare
- publish-clice.yml: add pixi_env matrix entries and wrap cross-compile cmake calls in `pixi run -e $ENV -- env -u LIBRARY_PATH ...` so the aarch64 linker cannot pick up conda host libs during release packaging. - build-llvm.py: move the env-var cleanup before build_native_tools so the native-tools configure isn't contaminated by target-arch link flags. - setup-llvm.py: produce a clear error when manifest entries lack the new `arch` field instead of silently returning "no match". - build-llvm.yml: upload cross-compiled clice artifacts and add a test-cross job that downloads them on native ARM/Intel runners and runs unit/integration/smoke tests. - update-llvm-version.py: add a --check mode and wire it into check-format so every PR verifies the setup_llvm(...) regex and manifest schema still match what the auto-PR job expects. - Remove decorative banner comments introduced by this branch across the workflow files, pixi.toml, and validate-llvm-components.py. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drop the "extra" arg workaround in pixi.toml now that pixi supports verbatim passthrough via `--`. Route all CI clice builds through pixi tasks (cmake-config/cmake-build/package-config) instead of raw cmake, so LLVM-path and toolchain conventions stay centralized. Move conda-flag clearing for cross builds into per-feature activation scripts (linux/macos/windows), using `export VAR=` which reliably overrides conda values; drop the `env -u LIBRARY_PATH` CI wrappers.
The new `--` passthrough syntax used in task invocations requires a recent pixi. Align CI with the local version used for verification.
Drop the only remaining inline `prefix-dev/setup-pixi` invocation so every workflow goes through `.github/actions/setup-pixi`. This keeps the pixi version pinned in a single place for future bumps.
Add smoke-test to the `test` pixi task and collapse the per-phase workflow steps into a single `pixi run test` invocation in build-llvm and test-cmake. This fills a gap in the native build-llvm job, which previously skipped the smoke phase, and keeps the one-command form identical between CI and local dev. The collapse drops the `if: success() || failure()` guard that used to run smoke even when integration failed. That signal is minor and not worth fanning the pipeline back out for.
4 tasks
This was referenced Jul 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds cross-compilation support for three new target platforms, upgrades LLVM to 21.1.8, and overhauls the CI pipelines around cross-builds and testing.
Cross-compilation
New target triples accepted via
-DCLICE_TARGET_TRIPLE=...:x86_64-apple-darwinaarch64-linux-gnuaarch64-pc-windows-msvccmake/toolchain.cmake— mapsCLICE_TARGET_TRIPLEtoCMAKE_SYSTEM_NAME/CMAKE_SYSTEM_PROCESSOR/compiler--target; picks up conda aarch64 sysroot when cross-compiling Linux.cmake/llvm.cmake— forwards target platform/arch tosetup-llvm.pyso the right prebuilt LLVM is downloaded for the target.CMakeLists.txt— uses a host-sideflatcfromPATHunderCMAKE_CROSSCOMPILINGinstead of the in-tree target build.pixi.toml:osx-64,linux-aarch64,win-arm64platforms.cross-macos-x64,cross-linux-aarch64(addsgcc_linux-aarch64+sysroot_linux-aarch64),cross-windows-arm64.test-runenv used on native ARM/x64 runners to execute cross-built artifacts (pulls in upstream clang+lld on macOS so tests don't fall back to Apple clang).scripts/activate_cross_linux.sh— exportsCONDA_PREFIX-relative paths for the aarch64 toolchain.scripts/build-llvm.py—--target-triplesupport and abuild_native_tools()helper that produces hostllvm-tblgen/clang-tblgenneeded when cross-compiling LLVM itself.LLVM upgrade 21.1.4 → 21.1.8
cmake/package.cmakebumpssetup_llvm("21.1.8").config/llvm-manifest.jsonregenerated with 6 new cross-compiled entries and a newarchfield on every entry so lookup is(version, platform, arch, lto, build_type).scripts/setup-llvm.py— honours the newarchfield when resolving artifacts.scripts/update-llvm-version.py(new) — single-call version bump acrosspackage.cmake+ manifest.scripts/validate-llvm-components.py(new) — scans the LLVM source tree for library targets and diffs them againstscripts/llvm-components.jsonto catch stale/misspelled component names before a build.scripts/llvm-components.json(new) — explicit allow-list of required LLVM/Clang library targets used bybuild-llvm.py.CI changes
.github/workflows/build-llvm.yml:workflow_dispatchwithllvm_version,skip_upload,skip_prinputs.build clice/ test / prune steps gated on!matrix.target_triplefor cross-builds; cross-built LTO entries apply the native prune manifest (arch-independent).file(1).uploadjob triggered byworkflow_dispatchpushes artifacts toclice-io/clice-llvmand hands the manifest off to the next job..github/workflows/test-cmake.yml:build_only: truecross entries that uploadbin/+lib/artifacts.test-crossjob runs on nativemacos-15-intel,ubuntu-24.04-arm,windows-11-armrunners, downloads the cross-built artifacts, and runs unit / integration / smoke tests under thetest-runpixi env.target_tripleso native and cross builds don't collide..github/workflows/publish-clice.yml:clice-x86_64-macos-darwin,clice-aarch64-linux-gnu,clice-aarch64-windows-msvc), each with a matching-symbolarchive.Compatibility
Debug+ ASAN remains disabled on Windows (llvm_mode == Debug && os == windows-*no longer appends-asan).🤖 Generated with Claude Code